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J^J (57) Abstract: The present invention describes how a trusted network routing authority, such as a VoIP inter-exchange carrier or 
O clearinghouse can provide routing and secure access control across multiple network domains with a single routing and admission 
O request. This technology can improve network efficiency and quality of service when an Internet Protocol (IP) communication 
N transaction, such as a Voice over IP (VoIP), must be routed across multiple devices or administrative domains. This technology 

O defines the technique of performing multiple route look-ups at the source of the call path to determine all possible routes across 
^ intermediate domains to the final destination. The VoIP inter-exchange carrier or clearinghouse then provides routing and access 
S permission tokens for the entire call path to the call source. 
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METHOD AND SYSTEM FOR ROUTING CALLS OVER 
A PACKET SWITCHED COMPUTER NETWORK 

STATEMENT REGARDING RELATED APPLICATIONS 
5 The present application claims priority to provisional patent application 

entitled, "Look Ahead Routing," filed on March 11, 2004 and assigned U.S. 
Application Serial No. 60/552,341. The entire contents of this provisional application 
are hereby incorporated by reference. 

10 TECHNICAL FIELD 

The present invention relates to communications over a packet switched 
computer network. More particularly, the present invention relates to routing for 
voice over Internet Protocol (VoIP) telephony. 

15 BACKGROUND OF THE INVENTION 

Telecommunications using~IP networks" and VoIP technology havejbecome a 
practical substitute for the traditional Public Switched Telephone Network (PSTN) 
that uses dedicated circuits or channels to convey telecommunications such as voice 
calls, facsimiles or video conferences. Unlike the PSTN model, the IP transmission 

20 model does not dedicate a network circuit or channel for a telecommunication session 
because a VoIP telecommunication session is transmitted via IP data packets. Two 
VoIP endpoints communicate directly across the IP network peer to peer. IP data 
packets, carrying the VoIP communication, are sent asynchronously from the source 
to the destination across the mesh of the IP network. 

25 One advantage of VoIP peer to peer communications is the elimination of 

costly network circuits and switches dedicated to voice conversations. With VoIP 
technology, voice conversations can be transmitted across the same IP data network 
used to transmit data applications such as e-mail and web browsing. The use of a 
single data network for all communications and the elimination of a circuit switched 

30 networks dedicated for voice communications can offer significant savings. 

A problem facing peer to peer VoIP communications, however, is the problem 
of global number discovery and interconnection. For example, the customers of a 
local telephone service provider expect to be able to send tQ and receive calls from 
any telephone number in the world. However, the telephone network of a single 
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service provider is limited. Therefore, to provide global calling services, the local 
service provider must be interconnected with all other telephone networks in the 
world. Interconnect agreements between telephone service providers typically require 
a mutual billing settlem ent agreement for intercon nect traffic exchange to ensure the 
5 terminating network is compensated for completing telephone calls. 

In the traditional PTSN model, this problem was solved by routing phone calls 
to the switch of a dominant inter-exchange carrier QXCs) with interconnection to any 
telephone number in the world. For example, the AT&T network is interconnected 
with the gateway switches of all national telephone provides and can ensure that a 

1 0 PSTN call can be routed to any telephone on Earth. 

The market model for VoIP is similar to the PTSN inter-exchange model, but 
it is not as simple in structure. In VoIP networks, traditional telephone numbers are 
correlated to EP addresses. VoIP service providers must be able to route telephone 
calls - dialed to traditional telephone numbers - to the IP address of the VoIP 

15 pro vider servi ng the called party. A solution to this routing discovery problem has 

been the development of VoIP inter-exchange carriers or clearinghouses. The VoIP 
inter-exchange carrier provides value by facilitating the exchange of calls between 
hundreds of VoIP service providers. To replicate the service of the VoIP inter- 
exchange carrier, each VoIP service provider would have to establish a bilateral 

20 interconnect agreement with every other VoIP service provider - a huge 
administrative task. 

Figure la illustrates one solution of the conventional art. The term 
"conventional art" as used in this specification is not statutory "prior art" under 35 
U.S.C. § 102(b). This conventional art is being presented only to explain Applicant's 
25 invention in terms of technology that is existing at the filing date of this specification. 
Therefore, Figures la-2b do not qualify as statutoiy prior art. 

The VoIP Carrier or Clearinghouse 100 of Figure la has interconnect and 
settlement billing agreements with a large number of VoIP operators around the 
world. The VoIP Carrier or Clearinghouse operates 100 the central database which 
30 correlates the telephone numbers and IP addresses for each VoIP service provider. 

While Figure la shows only one source and destination VoIP network, this 
example applies for a veiy large number of VoIP service providers. When the 
customer of the Source VoIP Network 110 dials a phone number that cannot be 
completed in the Source VoIP Network 110, the Source VoIP Network 110 will send 
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a Toute/access query 130 to the VoIP Carrier 100. The VoIP Carrier 100, which has 
the central routing database of all correlating telephone numbers and IP addresses, 
performs a route lookup to determine which IP address, or addresses, can terminate 

the VoIP call to the called number. ... _ ..... 

5 In the example illustrated in Figure la, the route/access query 130 from the 

VoIP Carrier 100 returns the IP address of the Destination VoIP Network 120. Given 
this information, the Source VoIP Network 110 performs a call setup 140 to the 
destination network 120 to complete the call to the called telephone number. 

It is important to note that the VoIP inter-exchange carrier or clearinghouse 

10 model differs from the circuit switched inter-exchange carrier model. In the circuit 
switched inter-exchange carrier model, the call is routed between the source and 
destination network via the inter-exchange carrier's switch. The inter-exchange 
switch is used for routing, inter-carrier access control and call detail record (CDR) 
collection for settlement billing. 

15 In the VoIP inter -exchange carri er or clearingh ouse mo del, the call is 

. transmitted peer to peer.from the source_to the destination directly across the mesh of 
the IP network. There is no switch in the call path to enforce inter-carrier access 
control or to collect call detail records. In the VoIP model, the inter-exchange carrier 
or clearinghouse enforces access control by including an access token with the IP 

20 address of a destination network. The source network then includes this access token 
in the peer to peer call setup request to the destination network. While the destination 
network probably does not recognize the source network, the destination will validate 
the access token to determine that the call was authorized by its trusted inter-exchange 
carrier or clearinghouse who will guarantee payment for terminating the call. 

25 Accounting for inter-carrier settlement billing is accomplished by call detail 

record collection from both the source and destination networks 110, 120. At the 
completion of the call, both the source and destination networks send call detail 
records to the VoIP inter-exchange carrier or clearinghouse. This is illustrated in 
Figure lb which shows VoIP Carrier 100 receiving a source call detail record 150a 

30 from the Source VoIP Network 110 and destination call detail record 150b from the 
Destination VoIP Network 120. 

The previous paragraphs describe the basic peer to peer VoIP clearing and 
settlement call scenario. However, technology limitations and market conditions have 
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created new variations of this basic call scenario that introduce an intermediate proxy 
device between the source and destination network. 

Figure 2a illustrates the presence of a VoIP Proxy Device or intermediate 
^network 200 for peer . to peer„calls between a source and destination VoEP network. 
5 Common reasons for routing peer to peer VoIP calls via a proxy device or 
intermediate network 200 are: (A) the proxy device acts as a firewall to allow 
signaling of VoIP traffic between a private IP network with private IP addresses and 
VoIP networks with public IP addresses; (B) the source and destination networks 110, 
120 use different signaling protocols and an inter-working device is required for 
1 0 protocol translation between the networks. 

The call scenario for a VoIP inter-exchange carrier or clearinghouse 100 when 
a proxy or intermediate network 200 is used is illustrated in Figure 2a and described 
below. When the customer of the Source VoIP Network 110 dials a phone number 
that cannot be completed in the Source VoIP Network 110, the Source VoIP Network 

15 110 will send a route/access query 130a to the VoIP Carrier 100. The VoIP Carrier 

100 performs a route lookup to determine which IP address, or addresses, can 
terminate the VoIP call to the called number. 

In the example illustrated in Figure 2a, the route/access query 130a from the 
VoIP Carrier 100 returns the IP address of the VoIP Proxy Device 200. Given this 
20 information, the Source VoIP Network 110 performs a call setup 140a to the VoIP 
Proxy Device 200. The VoIP Proxy Device 200 validates the access token in the call 
setup and accepts the call. If the VoIP Proxy Device cannot complete the call, it will 
send a route/access query 130b to the VoIP Carrier 100. The VoIP Carrier 100 
performs a route lookup and determines that the route to the called number from the 
25 VoIP Proxy Device 200 can be completed by Destination VoIP Network 120. 

The VoIP Carrier 100 returns the destination IP address in the route/access 
query response 130b to the VoIP Proxy Device 200. The VoIP Proxy Device 200 
then sends a call setup 140b to the Destination VoIP Network 120 which validates the 
access token and completes the call. 
30 Figure 2b illustrates how call detail records are reported to the VoIP Carrier 

100 when the call is finished. The Source VoIP Network 110 reports a source call 
detail record 150a for the first call leg. The VoIP Proxy Device 200 reports a 
destination call detail record 150c for the first call leg. The VoIP Proxy Device 200 
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reports a source call detail record 150d for the second call leg. The Destination VoIP 
Network 120 reports a destination call detail record 150b for the second call leg. 

Accordingly, there is a need in the art for a more simple routing method that 
does not require intermediate networks to communicate with a VoIP clearinghouse to 
5 place a call. There is further need in the art for a simplified routing method that can 
reduce a number of call detail records reported to a VoIP clearinghouse from one or 
more intermediate networks used to place a call. 

SUMMARY OF THE INVENTION 

10 A VoIP inter-exchange carrier or clearinghouse can provide routing and secure 

access control across multiple network domains with a single routing and admission 
request This technology can improve network efficiency and quality of service when 
an Internet Protocol (IP) communication transaction, such as a Voice over IP (VoIP), 
must be routed across multiple devices or administrative domains. 

15 -Ttas-teclmology-dei^s4he4echmqu route look-ups 

_ at-the source of the. call path to determine all possible routes across intermediate 
domains to the final destination. The VoIP inter-exchange carrier or clearinghouse 
then provides routing and access permission tokens for the entire call path to the call 
source. The call source, then establishes a communication session with the first 

20 intermediate network defined by the routing authority. The call source transmits the 
access permission token, provided by the routing authority, to the first intermediate 
network. The first intermediate network validates the token and accepts the call 
session from the call source. As part of the token validation process, the intermediate 
network extracts the IP address of the destination network from the token. The 

25 intermediate network may then use this information to complete the call to the 
destination network. This technology can also be applied to call scenarios that 
include multiple intermediate networks between the source and destination. 

According to one exemplary aspect of the technology, the VoIP inter- 
exchange clearinghouse can provide the call source with multiple call paths that can 

30 complete a call session. These call paths can be ranked by weight calculations. The 
weight calculations can be made by the VoIP inter-exchange clearinghouse based on 
weights assigned to each intermediate network and destination network that may be 
part of a particular call path. 
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According to another exemplary aspect, the VoIP inter-exchange 
clearinghouse can provide a token that includes optional legs for a call path. In other 
words, a token can include authorizations for numerous legs of a call path to address 

the possibility that a particular leg of a-call path-may fail. — 

5 The term, "VoIP Carrier or Clearinghouse," as defined in this specification 

comprises any single device or a plurality of devices that can identify call paths across 
a packet switched computer network and that can create permission tokens for 
networks that are part of a call path. The term, "source VoIP network," as defined in 
this specification comprises any single device or a plurality of devices that can 

10 originate communications. The term, "intermediate network," as defined in this 
specification comprises any single device such as, but not limited to, a proxy, or a 
plurality of devices that can route communications from a call source to other 
intermediate networks or destination networks. Similarly, the term, "destination 
network," as defined in this specification comprises any single device or a plurality of 

15 — devices~fliat-can-complete-communications-from-a-call_source or_an-intermediate 
network. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure la is a functional block diagram of a conventional packet switched 
20 network that has a source VoIP network that communicates with a VoIP carrier to 
complete a phone call. 

Figure lb is a functional block diagram of a conventional packet switched 
network that has a source VoIP network that communicates a call detail record to a 
VoIP carrier after a phone call is completed. 
25 Figure 2a is a functional block diagram of a conventional packet switched 

network that has a source VoIP network that communicates with a VoIP carrier and a 
VoIP proxy device/intermediate network to complete a phone call. 

Figure 2b is a functional block diagram of a conventional packet switched 
network that has a source VoIP network, VoIP proxy device/intermediate network, 
30 and a destination network that communicate call detail records to a VoIP carrier after 
a phone call is completed 

Figure 3a is a functional block diagram of an exemplary packet switched 
network that has a source VoIP network that communicates with a VoIP carrier that 
provides authorization tokens for a VoIP proxy device/intermediate network and 
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destination network to complete a phone call, according to one exemplary 
embodiment of the invention. 

Figure 3b is a functional block diagram of an exemplary packet switched 
networkjhat has_a.source VoLP_network,_-VoIP~proxy device/intermediate-network, 
5 and a destination network that communicate call detail records to a VoIP carrier after 
a phone call is completed, according to one exemplary embodiment of the invention. 

Figure 4 is a functional block diagram of an exemplary packet switched 
network that has a source VoIP network and a VoIP carrier or clearinghouse that can 
comprise a certificate authority, according to one exemplary embodiment of the 
10 invention. 

Figure 5 is a logic flow diagram illustrating an exemplary method for looking 
up routing destinations across a packet switched computer network according on one 
exemplary embodiment of the invention. 

Figure 6 is a continuation of the logic flow diagram of Figure 5 that illustrates 
15 additi onal steps for co m pletin g a cal l such as calculating weights of call paths and 
ranking call paths by calculated weights according on one exemplary embodiment of 
the invention. 

Figure 7 is a functional block diagram of an exemplary packet switched 

network in which a source VoIP network can have several call paths that can be used 
20 to complete a call, according to one exemplary embodiment of the invention. 

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS 

The present invention may be embodied in hardware or software or a 
combination thereof disposed within a packet switched computer network. The 

25 present invention relates to routing telephony calls from a source network to a 
destination network via an IP network. A telephone call occurring via an IP network 
is often referred to as a "voice over IP" transaction. When a "voice over IP" 
transaction specifically involves the Internet, the description "Internet telephony" may 
also used to describe the transaction. An exemplary embodiment of the VoIP 

30 clearinghouse will be described with respect to Internet telephony. However, the 
principles of the VoIP clearinghouse of the present invention apply to all IP routed 
transactions, including, but not limited to, "voice over IP" calls, "fax over IP" calls, 
and "video over IP calls." 
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Referring now to the drawings, in which like numerals represent like elements 
throughout the several Figures, aspects of the present invention and the illustrative 
operating environment will be described. 

— The-inventionriUustrated in Figure -3a can provide significant optimization of 

5 the call scenario described in Figure 2a by eliminating the need for the second 
route/access query 210. In Figure 3a, a customer of the Source VoIP Network 110 
dials a phone number that cannot be completed in the Source VoIP Network 110. The 
Source VoIP Network 110 sends a route/access query 130a to the VoIP Carrier 100. 
The VoEP Carrier 100 performs a route lookup to determine which IP address, or 

10 addresses, can terminate the VoIP call to the called number. In this route lookup, the 
VoIP Carrier 100 uses a routing algorithm that recognizes that the VoIP Proxy Device 
200 cannot complete the call and that a second call leg from the VoIP Proxy Device 
200 to the Destination VoIP Network 120 is required to complete the call. 

The VoIP Carrier 100 returns the route/access query response 130a with the IP 

4 5 -^address of-the -VoIPJtoxy-Device-200-and-a look.ahead_token._Embedded.in the look 
ahead token is the DP address of the Destination VoIP Network 120. Given this 
information, the Source VoIP Network 110 performs a call setup 140a to the VoIP 
Proxy Device 200. The VoIP Proxy Device 200 validates the access token in the call 
setup and accepts the call. 

20 In the token validation process, the VoIP Proxy Device recognizes the 

presence of the look ahead route to the Destination VoIP Network 120. The VoIP 
Proxy Device 200 then uses this IP address to complete the call to the Destination 
VoIP Network 120. The VoIP Proxy Device 200 then sends 140b a call setup to the 
Destination VoIP Network 120 which validates the look ahead access token and 

25 completes the call. 

Figure 3b illustrates how call detail records are reported to the VoIP Carrier 
100 when the call is finished. The Source VoIP Network 110 reports a source call 
detail record 350a for the call. The VoIP Proxy Device 200 reports a call detail 
record 350c of type "other" for the call. The Destination VoIP Network 120 reports a 

30 destination call detail record 350b for the call. 

One important component required for the most general use case of look ahead 
tokens is a secure method for inter-domain access authorization among multiple 
domains that have no knowledge of one another. The secure access control among 
anonymous peers is enforced by a common central authority which is trusted by all 
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peers. In VoIP, this authority is the VoIP inter-exchange carrier or clearinghouse 100. 
The use of Public Key Infrastructure (PKT) technology by a common certificate 
authority which digitally signs each inter-domain access token is a solution. 
_ _ - Asjllustrated.in Figure 4,.a VoIP inter-exchange. carrier-or. clearinghouse 100 
5 can comprise certificate authority 400 to establish a trusted cryptographic relationship 
with each VoIP service provider. In this example, three domains are presented: the 
Source VoIP Network 110, the VoIP Proxy Device 200 and the Destination VoIP 
Network 120. These domains aU may access each other and the certificate authority 
400 via an IP Network or Internet 410. However, it is valid to extend this example to 
10 include millions of domains. Each one of these domains, may be autonomous and 
anonymous from the others. They have no knowledge or agreement to allow the 
exchange of IP communication sessions via an IP network 410. Each domain, would 
however, have (1) the certificate and assymetric public key of the common certificate 
authority and (2) a local certificate, defining the domain identity, signed by the 

1 5 certifica te authorit y. _ _ 

With this public key infrastructure in place, it is possible for the VoIP inter- 
exchange carrier or clearinghouse 100 to digitally sign an inter-domain access token 
which allows a Destination VoIP Network 120 to validaterthat a call setup request 
direct from an unknown Source VoIP Network 110 has been authorized by a trusted 
20 third party - the VoIP inter-exchange carrier or clearinghouse. This application 
provides an implementation example using public key infrastructure service. 
However, those skilled in the art will recognize that this invention can be applied 
using other techniques for secure inter-domain access control, such as simple 
passwords or symmetric key encryption. 
25 With a mechanism in place, as described above, for a VoIP inter-exchange 

carrier or clearinghouse 100 to enforce inter-domain access control for direct peer to 
peer VoIP communications, the new art defined by this invention will be described 
below. The first innovation implemented by look ahead tokens is the multiple lookup 
routing algorithm. 

30 Referring to Figures 3a, 5, and 6, the following sections describe the process 

to create a look ahead token for multiple call paths. The description of the flow charts 
in the this detailed description are represented largely in terms of processes and 
symbolic representations of operations by conventional computer components, 
including a processing unit (a processor), memory storage devices, connected display 
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devices, and input devices. Furthermore, these processes and operations may utilize 
conventional discrete hardware components or other computer components in a 
heterogeneous distributed computing environment, including remote file servers, 
computer- servers,— and- memory— storage— devices. — Each— of -these-conventional 
5 distributed computing components can be accessible by the processor via a 
communication network. 

The processes and operations performed below may include the manipulation 
of signals by a processor and the maintenance of these signals within data structures 
resident in one or more memory storage devices. For the purposes of this discussion, 

10 a process is generally conceived to be a sequence of computer-executed steps leading 
to a desired result. These steps usually require physical manipulations of physical 
quantities. Usually, though not necessarily, these quantities take the form of 
electrical, magnetic, or optical signals capable of being stored, transferred, combined, 
compared, or otherwise manipulated. It is convention for those skilled in the art to 

1 5 -^efer-to jepresentations_of-these_signals_as-bits^-bytes, jwords, information, elements, 
.symbols, characters, numbers, points, data, entries, objects, images, files, or the like. 
It should be kept in mind, however, that these and similar terms are associated with 
-appropriate physical quantities for computer "operations, and that these terms are 
merely conventional labels applied to physical quantities that exist within and during 

20 operation of the computer. 

It should also be understood that manipulations within the computer are often 
referred to in terms such as creating, adding, calculating, comparing, moving, 
receiving, determining, identifying, populating, loading, executing, etc. that are often 
associated with manual operations performed by a human operator. The operations 

25 described herein can be machine operations performed in conjunction with various 
input provided by a human operator or user that interacts with the computer. 

In addition, it should be understood that the programs, processes, methods, etc. 
described herein are not related or limited to any particular computer or apparatus. 
Rather, various types of general purpose machines may be used with the following 

30 process in accordance with the teachings described herein. 

The present invention may comprise a computer program or hardware or a 
combination thereof which embodies the functions described herein and illustrated in 
the appended flow charts. However, it should be apparent that there could be many 
different ways of implementing the invention in computer programming or hardware 
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design, and the invention should not be construed as limited to any one set of 
computer program instructions. 

Further, a skilled programmer would be able to write such a computer 
program or identify the -appropriate hardware circuits- to implement -the- disclosed 
5 invention without difficulty based on the flow charts and associated description in the 
application text, for example. Therefore, disclosure of a particular set of program code 
instructions or detailed hardware devices is not considered necessary for an adequate 
understanding of how to make and use the invention. The inventive functionality of 
the claimed computer implemented processes will be explained in more detail in the 
10 following description in conjunction with the remaining Figures illustrating other 
process flows. 

Certain steps in the processes or process flow described below must naturally 
precede others for the present invention to function as described. However, the 
present invention is not limited to the order of the steps described if such order or 

15 "sequence does not alter the functionality of the present invention. That is, it is 
recognized that some steps may be performed before, after, or in parallel other steps 
without departing from the scope and spirit of the present invention. 

Again, referring now to Figure 5, the process starts when the VoIP Carrier 100 
receives a routing/access query 130a from a Source VoIP Network 110. The query 

20 130a is processed by a routing algorithm that starts with step 500 on Figure 5. 

The first step 510 in the routing algorithm is to determine which destination IP 
addresses have been defined to complete calls from the source network 110 to the 
called number 510. Criteria used to determine routing of calls from the source 
network or device 110 to intermediate networks 200 or destination devices or 

25 networks 120 may include, but is not limited to, business policies; quality of service 
requirements; interconnect pricing or credit policies defined specifically for the source 
network 110 and/or intermediate networks 200, destination networks or devices 120; 
weights assigned to intermediate networks 200 and destination networks or devices 
120 that are used to determine how calls are load balanced or distributed across 

30 multiple intermediate and destination networks or devices 120, 200 serving the same 
called number and by device or network; properties defined for the source networks 
110, intermediate networks 200, and destination networks or devices 120 that indicate 
technical capabilities, compatibilities, and protocol inter-working. The criteria 
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described above used by the routing algorithm illustrated in Figure 5 can be 
provisioned or assigned by the VoIP carrier or clearinghouse 100. 

The results of step 510 will be a list of IP addresses for intermediate networks 
-200-and destination-devices-or- networks 120 and a corresponding weight-parameter 
5 which defines how the intermediate and destination devices 200, 120 will be ordered 
in priority. The source network 110 will use the order priority to determine which 
destination to attempt first if there are multiple devices serving the same called 
number. 

Once this list of destination IP addresses has been determined in step 520, the 

10 list of devices is looked through or reviewed by the IP addresses, and it is determined 
which devices are VoIP proxy devices that support the functionality to validate a look 
ahead token and extract the routing information required for the next call leg of a call 
path. Step 520 can be facilitated by adding a property to the VoIP device definition 
that indicates that a particular device supports look ahead tokens. If the destination is 

15 not-a-VoIE-proxy^the_device-^ 

5.7_0 determines if all potential destinations have been analyzed by step 520. If so, the 
routing algorithm proceeds to step 580. If not, the routing algorithm returns to step 
-520 to continue iterating-through the original list of destination devices. 

If step 520 determines that a destination device is a VoIP proxy 200 that 

20 supports look ahead tokens, the next step is step 540 in which it is determined if the 
destination network 120 or intermediate network 200 may originate calls. For 
business policy or other reasons, the VoIP Carrier may not allow calls to be originated 
or forwarded from the VoIP proxy. If this is the case, the network is removed from 
the list in step 545 and the routing algorithm returns to step 520 to analyze the next 

25 device or network 120, 200 in the list of networks 120, 200. 

If step 540 determines that the VoIP proxy or intermediate network 200 may 
originate or forward calls, the next step is to perform a second route lookup in step 
550 based on the routing policies defined for the VoIP proxy device or intermediate 
network 200. If destinations for the VoIP proxy device/network 200 are identified in 

30 the second route look-up, in step 560, they are added to the final output list of 
destinations. These final destination devices are linked to the VoIP proxy 200 in the 
output list and will be included in a look ahead token created for call authorization to 
the VoIP proxy 200. 

42- 
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After step 560, this portion of the routing algorithm returns to step 570. If all 
destinations in the original list defined in step 510 have been analyzed, the routing 
algorithm proceeds to step 580. If not, the routing algorithm loops back to step 520. 
— - — > For-sjmplicity, Figure-S-Olustrates-the routing-algoritei r when the destinations 
5 defined in step 550 are the final destination for call termination. However, this 
invention also incorporates the functionality of supporting multiple intermediate VoIP 
proxies between the source and destination networks. In the case where the 
destination device for the second call leg is a VoIP proxy or intermediate network 
200, the routing algorithm would return to step 540 and continue to loop through steps 

10 540 and 550 until the entire chain of VoIP proxies and final destination device are 
identified. When this occurs, the list of linked devices referred to as "call paths" 
would be submitted together as a group to the final destination list. Figure 7 is 
provided as an illustration of this functionality. 

Referring now to Figure 7, item 110a represents the Source Network. In this 

15 exa mple, a call to-called number-ca n be .completed by_four different destination 
.devices: Destination 1, 120a; Destination 2, 120b; Destination 3, 120c; Destination 4, 
120d; and Destination 5, 120e. The arrows indicate the possible call paths from the 
Source Network 110b, through the different VoIP Proxies 200a, 200b and 200c to the 
final destination devices and directly to Destination 5, 120e. 

20 The final output list of route destinations or call paths from the example 

presented in Figure 7 would be as follows: 
Voice Proxy 1 to Destination 1 
Voice Proxy 1 to Destination 2 
Voice Proxy 2 to Voice Proxy 3 to Destination 2 

25 Voice Proxy 2 to Voice Proxy 3 to Destination 3 
Voice Proxy 2 to Destination 4 
Destination 5 

After the routing algorithm completes through the iteration of multiple route 
look-ups as described in Figure 5, the process continues to step 600 as illustrated in 
30 Figure 6. The next function is to adjust destination weights of look ahead tokens for 
call paths in step 610. There are two methods for adjusting destination weights for 
look ahead tokens: a basic method and a normalized weights method. 

The basic method simply multiplies the weights of each device in a call path. 
This approach is simple and works well when all possible call paths traverse the same 
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number of devices. However, the basic method can lead to unexpected routing 
distribution when the alternative call paths traverse a different number of intermediate 
proxy devices. 

Refemng-briefly -to Figure J7,JTable_l-.below_pro\ades^-e?^ple^justing 

5 weights using the basic method. 



Table 1 - Basic Weight Method 





First 
Call Leg 


Second 
Call Leg 


Third 
Call Leg 


Call Path Weight 


Percent 
of total 


Call Path 


VoIP Proxy 1 


Destination 1 








Weights 


1 


1 




1*1=1 


2.94% 


Call Path 


VoIP Proxy 1 


Destination 2 








Weights 


1 


2 




1*2=2 


5.88% 


Call Path 


VoIP Proxy 2 


VoIP Proxy 3 


Destination 2 






Weights 


2 


4 


2 


2*4*2=16 


47.06% 


-Gall-Path 


— VoIP-Proxy-2_ 


_VoIP_Proxy3_ 


_Destination.3 
















Weights 


2 


4 


1 


2*4*1=8 


23.53% 


Call Path 


VoIP Proxy 2 


Destination 4 








Weights 


2 


2 




2*2=4 


11.76% 


Call Path 


Destination 5 










Weights 


3 






3 


8.82% 


Total 








34 


100.00% 



In the previous example using the basic method of adjusting call path weights, 
10 calls from the Source Network 110a will be distributed as follows: three out of 
thirty-four calls, 8.82%, will be routed to VoIP Proxy 1 200a, twenty-eight out of 
thirty-four calls, 82.35%, will be routed to VoIP Proxy 2 200b and three out of thirty- 
four calls, 8.82%, will be routed to Destination 5 120a. 

The normalized method differs from the basic method by normalizing the 
15 weights of each device by dividing each device weight by the sum of all device 
weights in the same call leg as illustrated in Table 2 below: 
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Table 2 - Normalized Weight Method 





First 
Call Leg 


Second 
Call Leg 


Third 
Call Leg 


Call Path Weight 


Percent 
of total 


Call Path 


VoIP Proxy 1 


Destination! 








Weights 


1 


1 





l*l/(l+2)=l/3 


5.56% 


Call Path 


VoIP Proxy 1 


Destination 2 








Weights 


1 


2 




l*2/(l+2)=2/3 


11.11% 


Call Path 


VoIP Proxy 2 


VoIP Proxy 3 


Destination 2 






Weights 


2 


4 


2 


2*4/(4+2)*2/(2+l)=8/9 


14.81% 


Call Path 


VoIP Proxy 2 


VoIP Proxy 3 


Destination 3 






Weights 


2 


4 


1 


2*4/(4+2)*l/(2+l)=4/9 


7.41% 


Call Path 


VoIP Proxy 2 


Destination 4 








Weights 


2 


2 




2*2/(4+2)=2/3 


11.11% 


Call Path 


Destination 5 










Weights 


3 






3 


50.00% 


Total 








6 


100.00% 



In the previous example using the normalized method of adjusting call path 
weights, calls from the Source Network 110a will be distributed as follows: one out of 
5 six calls, 16.67%," will be^diit^d to VoIP Proxy 1 200a, two oufcrf six calls, 33.33%, 
will be routed to VoIP Proxy 2 200b and three out of six calls, 50.00%, will be routed 
to Destination 5 120e. 

After weights have been adjusted for each call path, the next step is to adjust 
the list of destinations for duplicates 620. As the example in Figure 7 illustrates, look 
10 ahead routing can result in duplicate destinations - Destination 2 120b js a duplicate 
destination. The VoIP Carrier may choose as policy to eliminate call paths which 
lead to the same destination multiple times. 

This feature is a configurable parameter in the look ahead routing algorithm 
which allows the VoIP carrier three choices: (1) never eliminate call paths that lead to 
15 the same destination, (2) when multiple call paths lead to the same destination, keep 
the call path with the highest weight and eliminate all other call path choices, or (3) 
only eliminate call paths for look ahead routes that lead to a duplicate destination. 

Referring now to Figure 6, the next step 630, is to rank the order of the call 
path choices based on their weights. The call paths may be rank ordered based on 
20 their weights, randomly ordered based on the weights, or randomly ordered regardless 
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of weight. When call paths are rank ordered, the call paths are ranked according to 
their weight. The call path with the highest weight is usually first while the call path 
with the lowest weight is typically last 

J^en^aU_paths_are_^^^ is used to 

5 determine the probability a call path is randomly selected before other call paths. For 
example, if there are two call paths - Call Path A has a weight of one and Call Path B 
has a weight or three - then there is a 75% (1/(1+3)) probability that Call Path B will 
be rank ordered first and a 25% (1/(1+3)) probability that Call Path A will be rank 
ordered first. 

10 After ordering call paths, the next step 640 is to generate an authorization 

token for each call path. The token is an information set which uniquely authorizes 
the specific call for which the token is created. The token typically includes, or is 
packaged with, some information that a VoIP proxy 200 or destination network 120 
can use to validate that the call was authorized by the VoIP carrier. The VoIP proxy 

15 200~orde sti na^o^ request thaTdoeThbt include a valid 

token. 

Those of ordinary skill in the art of security techniques will recognize there 
are many ways a token can be secured from tampering, such as, by the use of secret 
passwords or more commonly by signing the token with a digital signature. For 

20 example, the VoIP carrier 100 will sign an authorization token with its private key. 
The destination network 120 will then validate token using the VoIP carrier's public 
key. If the signature is valid, then the destination network 120 can be certain the 
token has not been altered since it was signed with the private key of the VoIP carrier. 
An example of a standard authorization token, as used in the call scenario 

25 presented in Table 3 shown below. This token, written in XML format, provides 
information that uniquely authorizes the call. 
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TABLE 3 - TOKEN WRITTEN IN XML FORMAT 

<TokenInfo random^ 30113 f > 

<SourceInfo type=' el64 I >4045266060</Sourcelnfo> 
5 <DestinationInf o type= r el64 1 >25'64286000</Destinatiohlnf 6>~ ~ 
<CallId 

encodings r base64 1 >NjMzMDYxMzgzMDMxMzA2MTMyMzAzMDAwMDA=</CallId> 
<ValidAfter>2004-12-02T20:37:58Z</ValidAfter> 
<ValidUntil>2004-12-02T20 : 47 : 58Z</ValidUntil> 
10 <TransactionId>4733140074823188489</TransactionId> 
<UsageDetail> 

<Amount >1 4 4 0 0< /Amoun t> 

<Increment>K/Increment> 

<Service/> 
15 <Unit>s</Unit> 
</UsageDetail> 
</TokenInfo> 

This token authorizes a call, lasting up to 14,400 seconds from calling number 

4045266060 to- — called -number- 2564286000, with Callld 

20 NjMzMDYxMzgzMDMxMzA2MTMyMzAzMDAwMDA during a ten minute period between 8:37- 
8:47 p.m. on December 2, 2004. 

It is noted here that the information in a look ahead token is not limited to the 
information fields presented in the example above. Any relevant information may be 
included in a look ahead token. Examples of data fields which are readily useful for 

25 look ahead tokens are listed below Table 4: 



TABLE 4 - EXAMPLES OF LOOK AHEAD TOKEN DATA FIELDS 



Information Element 


Note 


Version 


Version of the token 


Random number 


Any randomly generated number 


Transaction ID generated by the 
settlement server 


A unique number identified for the call 


Contact ID 


Identifies the Settlement Service provider 


Valid after time 


Call must be setup after this time 


Valid until time 


Call must be setup before this time 


Calling Number 


Number of the calling party 
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Information Element 


Note 


Calbng Party Identification 


Text description of calling party, i.e. John 
and Jane Doe. 


Called Number - - 


. Number-of-the called party 


Amount - Usage Detail 


Amount of usage authorized 


X t XT ^ X™\ _ j *1 

Increment - Usage Detail 


Number of units per increment 


Units - Usage Detail 


Seconds, packets, bytes, pages, calls 


Currency - Pricing Indication 


Currency of transaction, i.e. USD 


Setup - Pricing Indication 


Fixed price per call 


Amount - Pricing Indication 


Price per increment 


increment — rricing incnoaLiuii 


T Ttii+q npf •JnPTPiTipn'f' 

KJ 111 Lo pt>l lllUlt/lilvlll 


Units - Pricing Indication 


Seconds, packets, bytes, pages, calls 


Type of service 


Service requested. Default is voice. 


Destination address 


Used for look ahead routing 


Destination trunk group 


Used forlookahead routing- 


Destination protocol 


Used for look ahead routing 


OSP Version 


Used for look ahead routing 


Call Identifier 


Umque identifier for the call 


Group ID (i.e for conference call 
admission) 


SameasConferenceIDmH.323. Calls 
with unique Calllds can share a common 
GroupID. i.e a conference call. 


Data Rate 


Data rate requested for the call 


Number of Channels 


Number of channels requested 


Bandwidth 


Amount of bandwidth reserved 


Quality of Service 


Level of service quality requested 


Quality of Service Class 


Class of service quality requested 


Answer seizure xvano iaoKJ 


V^dll oumpicLiuii laUU 


Mean Hold Time (MHT) 


Average call duration 


Post Dial Delay (PDD) 


Time between call initiation and the first 
ring at the called telephone. 



For a call path which includes a VoIP proxy 200, as illustrated in Figure 3a, a 
single look ahead token can provide routing authorization for both the first call leg 
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and the second call leg. A look ahead token will include all the information required 
for the first leg of the call to the VoIP proxy 200, plus the required routing 
information to the destination network 120. Below in Table 5 is an example of a look 
ahead token that is routed first to a VoIP proxy 200 and includes the routing 
5 information to the final destination network 120 with IP address 1 .2.3.4. 



TABLE 5 - EXAMPLE OF XML FORMATTED LOOK AHEAD TOKEN 
<TokenInfo random= f 30113 '> 

<SourceInfo type= ? el64 , >4045266060</Sourcelnfo> 
10 <DestinationInfo type= f el64 ■>2564286000</Destinationlnf o> 
<CallId 

encodings base64 1 >NjMzMDYxMzgzMDMxMzA2MTMyMzAzMDAwMDA=</CallId> 
<ValidAf ter>2004-12-02T20 : 37 : 58Z</ValidAf ter> 
<ValidUntil>2004-12-02T20 : 47 : 58Z</ValidUntil> 
15 <TransactionId>4733140074823188489</TransactionId> 
<UsageDetail 

<Amount>14 4 00^Amount>— ~ " " ■ — 

<Increment>K/Increment> - - 

<Service/> 
20 <Unit>s</Unit> 
</UsageDetail> 
<LookAhead> 
KDestinationAlternate 

type= 1 transport '>[1.2.3.4 ]</DestinationAlternate> 
25 <DestinatlonProtocol>SIP</DestinationProtocol> 
<OSPVersion>2. 1 . K/OSPVersion> 
</LookAhead> 
</TokenInfo> 

Note that the first thirteen lines of the look ahead token in Table 5 are identical 
30 to the standard token. The look ahead information is the three lines, in italics, 
between the LookAhead tags. The look ahead information includes: (1) the IP 
address of the destination network <Destinat±onAlternate 
type-' transport '>[■! .2.3.4 ]</DestinationAlternate> (2) the signaling 
protocol required by the destination network 

35 <DestlnatlonProtocol>SIP</DestinationProtocol> 

and (3) the Open Settlement Protocol version supported by the destination network 
<ospversion>2.i.i</ospversion>. The look ahead token can include other 
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information, such as destination trunk group, required to complete the call to the 
destination network.. 

Call paths with multiple VoIP proxies 200 would include multiple look ahead 
destinations listed in sequential order as logically defined by the call path with the 
5 final destination as the last information set before the end of the token. It is also 
important to note that a look ahead token can contain not on a call path with multiple 
intermediate destinations, but also multiple call paths. 

Figure 7 provides an example of call scenario that requires a look ahead token 
with two call paths and a call path with an intermediate network before the final 
10 destination. The call scenario described by Figure 7 will result in three destinations 
and tokens provided to the source network 110a. 

The first route is to Voice Proxy 1 200a. The token for this route includes look 
ahead routing information for Destination 1 120a and Destination 2 120b. The 
second route is to Voice Proxy 2 200b. The token for this route includes look ahead 
1 5 routing to Voice Proxy 3 200c and Destinatio n 4 1 20d . Th e third route is Destination 
5 120e. 

Below is the look ahead token required for the second route in Figure 7. It 
provides an example of a look ahead token with both multiple call paths and 
intermediate networks For this example, IP addresses in the DestinationAlternate 
20 fields have been replaced with figure references. The first look ahead route in this 
token provides routing information for the call path from Voice Proxy 2 200b to 
Voice Proxy 3 200c then two call paths from Voice Proxy 3 200c to Destination 2 
120b and Destination 3 120c. The second look ahead route in this token provides 
routing information for the call path to Destination 4 120d. 
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<TokenInfo random=* 30113 ■> 

<SourceInfo type= T el64 , >4045266060</Sourcelnfo> 
<DestinationInfo type= f el64 »>2564286000</Destinationlnfo> 
5 <CaTlId~ 

encodings »base64 ' >NjMzMDYxMzgzMDMxMzA2MTMyMzAzMDAwMDA=</CallId> 
<ValidAf ter>2004-12-02T20 : 37 : 58Z</ValidAf ter> 
<ValidUntil>2004-12-02T20:47:58Z</ValidUntil> 
<TransactionId>4733140074 8231884 89</TransactionId> 

10 <UsageDetail> 

<Amount>l 4 4 00< /Amount > 

<Increment>K/Increment> 

<Service/> 

<Unit>s</Unit> 
15 </UsageDetail> 
<LookAhead> 

<DestlnationAlternate type= ' transport *> [200c]</DestinationAlternate> 
<Dest±nationProtocol>H323-Q93K/DestinationProtocol> 
<OSPVersion>l . 3. 4</OSPVersion> 
20 <LookAhead> 

<DestinationAlternate type=* transport' > [120b] </DestinatlonAlternate> 
<DestinationProtocol>SIP</DestinationProtocol> 
< OSPVersion>2 .1.1 </OSPVersion> 
</LookAhead> 
25 <LookAhead> 

<DestxnationAlternate type^ ' transport '>{120c]</DestlnationAlternate> 
<Dest±nationProtocol>SIP</DestinationProtocol> 
<OSPVerslon>2 . 1 . K/OSPVersion> 
</LookAhead> 
30 </LookAhead> 
<LookAhead> 

<Destina tionAl terna te type= ' transport '>[ 120d] </Destina tionAl terna te> 
<DestinationProtocol>H323~Q93K/Dest±nat±onProtocol> 
<OSPVersion>l . 3 . 4</OSPVersion> 
35 </LookAhead> 
</TokenInfo> 
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In tins exemplary call scenario, Voice Proxy 2 200b would validate the token 
received from Source Network 110a and extract the first look ahead DP address which 
is Voice Proxy 3 200c. Voice Proxy 2 200b would then send a call setup to Voice 
-Proxy-3-200c. -If-the call attempt is successful,-Voice Proxy 3 200c would validate the 
5 token and recognize that the first look ahead destination was its own address. The 
second VoIP 200b proxy would ignore this address and would extract the next IP 
address, Destination 2 120b as the next destination. Voice Proxy 3 200c would the 
route the call to Destination 2 120b. Destination 2 120b would validate the token and 
would recognize that its IP address as the last destination. The final destination 120 
10 would then complete the call to the called telephone number. 

If the call attempt from Voice Proxy 3 200c to Destination 2 120b is 
unsuccessful, Voice Proxy 3 200c will retry the call to the second look ahead route, 
Destination 3 120c. If the call attempt is successful, Destination 3 120c will validate 
the token and complete the call. 

15 If the call attempt from Voice Proxy 3 200c to Destination 3 120c is not 

successful the call attempt retry options for Voice Proxy 3 200c will be exhausted. 
Voice Proxy 3 200c will signal Voice Proxy 2 200b that it cannot complete the call. 
-Voice Proxy 2 200b will then retry the -call attempt using its second call path to 
Destination 4 120d. If the call attempt to Destination 4 120d is successful, the call 
20 will be completed to the called number. The call attempt is not successful, the call 
attempt retry options for Voice Proxy 2 200b will be exhausted. Voice Proxy 2 200b 
will then signal Source Network 110a that it cannot complete the call. 

The tokens presented in previous examples use a XML syntax. However, this 
same invention can be applied to tokens of any syntax. For example, Table 6 below 
25 defines ASCII tags for token information elements. The corresponding XML tag is 
presented in the left hand column. 
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- ASCH TAGS FOR TOKEN INFORMATION ELEMENTS 



Tag 


Information Element 


XML Tag 


V 


Version 


<Version> 


r 


Random Number 


<TokenInfo random=» 30113 f > 


I 


Transaction ID generated by 
the settlement server 


<TransactionId> 


X 


ContactID 




a 


Valid Alter lime 


V V ax JLUXVL tci ^ 


u 


Valid Until lime 




c 


Calling Number 




T 
J 


ailing jr arty laennncaiioii 


<CallinaPartvId> 


r* 




<DestinationInfo> 


TVyf 

IVl 


Ammint TTqsop Dptail 


^/unOuTlt.^ ^WlUllll vUSdyclJcLall'' lagoj 


n 


Tnrrprnprit T T<?app Dptail 




U 


Units -Usage Detail . .-. 


<Units> (within <UsageDetail> tags) 


y 


v> UITCIlwy — ± IILlllg JJlUlV/aUUU 


<currency> ^wiloxq srricinginQicaLion? uxgaj 


p 


ocLup — r rimig jLU.uj.L-d.uuii 


<oetup> ^wiuiiii <fricinginaicaLion^ uxgoj 


m 


/vrnouni - rncing incucauon 


<Amount> ^Wluun <Pricinginaication> uigsj 


N 


Increment - Pricing Indication 


<Increment> (within <PricingIndication> 
tags) 


f 


Units - Pricing Indication 


<Units> (within <PricingIndication> tags) 


s 


Type of service 


<Service> 


d 


Destination address for look 
ahead routing 


<DestinationAlternate type=' transports 


e 


Destination trunk group for 
look ahead routing 


<DestinationAlternate type=' network' > 


D 


Destination protocol for look 
ahead routing 


<DestinationProtocol> 


0 


OSP Version for look ahead 
routing 


<0SPVersion> 


K 


Look Ahead tag 


<LookAead> 


i 


Call Identifier 


<CallId encoding='base64 f > 
Callld may or may not be encoded 
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G 


" J* TT"\ 

Group ID 


<Groupia> 


R 


Data Rate 


<DataRate> 


■L. 

D 


"KTnmher of Channels 


<NumberOf Channel s> 


-B-- 


-Bandwidth 


<Bandwidth>. - 


Q 


Quality of Service 


<QualityOfService> 


q 


Quality of Service Class 


<QoSClass> 



For further illustration, a comparison of identical look ahead tokens in XML 
format and ASCII format is provided below. The look ahead information of the 
tokens are in italics. The tokens described below would apply to a call with one 
5 intermediate VoIP proxy 200 and a destination network 120 as illustrated in Figure 
3a. Note that these look ahead tokens have been expanded to include additional 
pricing indication information. The pricing indication information documents what 
the VoIP carrier 100 will pay the VoIP proxy operator and the destination network 

operator tocomplete^ie-call— 

10 - In this example, the operator of the VoIP proxy will be paid $0.01 USD per 60 
seconds to transmit the call. The call setup fee is $0.00 USD. The destination 
network will be paid $0.02 USD per 60 seconds to complete the call. The call setup 
fee is $0.00 USD. 

15 <TokenInfo random= f 30113 '> 

<SourceInfo type='el64 , >4045266060</Sourcelnfo> 
<DestinationInfo type='el64 1 >2564286000</Destinationlnf o> 
<CallId 

encodings l base64 f >NjMzMDyxMzgzMDMxMzA2MTMyMzAzMDAwMDA=</CallId> 
20 <ValidAfter>2004-12-02T20:37:58Z</ValidAfter> 
<ValidUntil>2004-12-02T20 : 47 : 58Z</ValidUntil> 
<TransactionId>4733140074823188489</TransactionId> 

<UsageDetail> 

<Amoun t> 144 0 0< / Amount> 
25 < Incr ement> 1< / Increments 
<Service/> 
<Unit>s</Unit> 
</UsageDetail> 
<PricingIndication> 
30 <Currency>USEK/Currency> 
<Setup>0<Setup> 
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.> <Amount>0. OK /Amount > 
< Increment > 6 0< / Increment > 
<Unit>s</Unit> 
</PricingIndication> 
5 <LookAhead>- 

<DestinationAlternate 

type= ' transport *>[1.2.3. 4]</DestinationAl terna te> 

<DestinationAlternate type=' network' >TrunkGrpl<DestlnatlonAlternate> 
<DestinatlonProtocol>H323-Q93K/DestinationProtocol> 
10 <OSPVersion>l . 3 . 4</OSPVersion> 
<Pri cinglndi ca tion> 

<Currency>USD</Currency> 

<Setup>0 <Se t up> 

<Amount>0. 02</Amount> 
1 5 <In cremen t> 60</In cremen t> 

<Un±t>s</Unit> 
</PricingIndication> 
</LookAhead> 
</TokenInfo> 

20 

Example token in ASCII format 

r=30113 

c=4045266060 
25 C=2564286000 

i= NjMzMDYxMzgzMDMxMzA2MTMyMzAzMDAwMDA= 

a=2004-12-02T20 : 52 : 30Z 

u=2004-12-02T21:02:30Z 

1=4733144047667937289 
30 A=14400 

n=l 

s= 

U=s 

y=USD 
35 p=0 

m=0.01 

N=60 

f=s 

cKL.2.3.4 
40 e=TrunkGrpl 
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D=H323-Q931 
o=1.3.4 
y=USD 
p=0 
5 m=0.02 
N=60 
f=s 

Referring briefly back to Figure 6, after the appropriate token has been 
generated for call path in step 640, the final step 650 is to return the routing 
10 information and token to the source network. 

While this invention has been described in detail with particular reference to 
preferred embodiments thereof, it will be understood that variations and modifications 
can be effected within the spirit and scope of the invention as described hereinabove 
and as described in the appended claims. 
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CLAIMS 

WHAT IS CLAIMED IS: 

1. A method for completing a phone call over a computer network, 
5 comprising: 

scanning the computer network for destination networks that are able 

to complete the call; 

scanning the computer network for intermediate networks that are 
linked to one of another intermediate network and a destination network capable of 

1 0 completing the call; 

for each intermediate network that is discovered, determining if the 
intermediate network is capable of further routing the call to one of another 
intermediate network and destination network; 

forming a list of one or more call paths, each call path comprising at 
15 least one of an intermediate network for further routing the call and a destination 
network for completing the call; 

generating an authorization token for each network in a call path; and 
providing access to the list in response to the request for competing the 

call. 

20 

2. The method of Claim 1, wherein generating an authorization token 
further comprises generating the authorization token comprising a list of alternate 
networks that can service a call in case of call failure. 

25 3. The method of Claim 1, wherein generating an authorization token 

further comprises generating the authorization token comprising pricing information 
for servicing a call. 

4. The method of Claim 1, wherein generating an authorization token 
30 further comprises generating the authorization token comprising quality of service 

information. 

5. The method of Claim 1, further comprising calculating weights for 
each call path in the list 
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6. The method of Claim 1, further comprising ranking an order of the list 
based on weights associated with each network. 



7. The method of Claim 5, wherein calculating weights for each call path 
5 further comprises multiplying weights of each network in a call path. 

8. The method of Claim 5, wherein calculating weights for each call path 
further comprises normalizing the weights of each network in a call path 

10 9. The method of Claim 8, wherein normalizing the weights of each 

network in a call path further comprises dividing a weight of each network by a sum 
of all weights in a same call leg. 

10. The method of Claim 1, further comprising adjusting the list for 
1 5 duplicate call paths. 

11. The method of Claim 10, wherein adjusting the list for duplicate call 
paths further comprises keeping call paths with higher weights and removing call 
paths from the list with lower weights. 

20 

12. The method of Claim 10, wherein adjusting the list for duplicate call 
paths further comprises removing call paths from the list that use a same intermediate 
network or a same destination network. 

25 13. The method of Claim 1, wherein generating an authorization token for 

each network in a call path further comprises generating authorization tokens for 
alternate networks in a call path when alternate networks exist in a particular call 
path. 
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14. A system for completing phone calls over a packet switched computer 
network, comprising: 

a source network for originating a phone call; 

an intermediate -network for-routing -the phone call_and_operatively 
5 linked to the source network; 

a destination network for completing the phone call and operatively 
linked to the intermediate network; 

a clearinghouse database operatively linked to the source network, the 
intermediate network, and the destination network; the clearinghouse database 
10 comprising data for correlating telephone numbers and computer network addresses 
and data describing relationships between intermediate networks and destination 
networks, the clearinghouse database forming a list of one or more call paths that 
comprise at least one of an intermediate network for further routing the call and a 
destination network for completing the call, the clearinghouse database generating an 
15 -authorization -tx)ken-for-each-network.ina.call_pafli — _ 

15. The system of Claim 14, wherein the clearinghouse database 
determines if each intermediate network is capable of further routing the call-to one of 
another intermediate network and destination network. 

20 

1 6. The system of Claim 14, wherein each intermediate network comprises 
a voice over internet protocol proxy device. 

17. The method of Claim 14, wherein at least one destination network 
25 comprises a voice over internet protocol destination network. 
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18. A method for completing a voice over Internet protocol phone call, 
comprising: 

scanning the Internet for destination networks that are able to complete 

the call; — 

5 scanning the Internet for intermediate networks that are linked to one 

of another intermediate network and a destination network capable of completing the 
call; 

for each intermediate network that is discovered, determining if the 
intermediate network is capable of further routing the call to one of another 
10 intermediate network and destination network; 

forming a list of one or more call paths, each call path comprising at 
least one of an intermediate network and a destination network; 

generating an authorization token for each network in a call path; and 
ranking the list of call paths based on weights associated with each 
15 — network in a call path. 

19. The method of Claim 18, further comprising calculating weights for 
each call path in the list. - — 

20 20. The method of Claim 18, further comprising adjusting the list for 

duplicate call paths. 
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